This section describes some of the background technologies that are important to the understanding of the race logic detection technology.
A. Circuit Models for Race Logic Analysis
Referring to FIG. 2, a user IC design is modeled as a directed graph consisting of a series of process blocks (or logic gates) connected by a set of signals. The process blocks (e.g., boxes L1 7, L2 8, L3 9 and L4 10 in FIG. 2) perform the logic operations of the IC design, such as addition, subtraction, multiplication, division, or memory read/write, whereas signals (e.g., I1, I2, x1, O1, O2 and O3 in FIG. 2) transport discrete logic data among process blocks, Signals in IC design may be single-bit or multiple-bits. A signal is a trigger signal of a process block if any changes in state of that signal will cause the process block to be evaluated (executed). A signal may trigger a process box when: its state changes from logic 0 to logic 1 (posedge trigger); its state changes from logic 1 to logic 0 (negedge trigger); whenever its state changes (anyedge trigger); or its state is either logic 1 or logic 0 (level-sensitive trigger).
In addition to the above, users may also specify propagation delays on process blocks and/or signals to model actual times consumed when those logic gates process data, and when data is transported from one end of a signal to the other end.
Furthermore, a circuit may contain one or more registers. Registers may be single- or multiple-bits. They are used to store data on a temporary basis. These data are later read and used in other circuit operations.
The aforementioned directed graph and propagation delays provide a realistic model of an IC design. The RaceCheck program compiles an IC design's HDL source files and creates a design database that contains a directed graph and the associated timing data for the IC design. The RaceCheck's static and dynamic race logic analysis routines then process the information in the design database to detect race logic in the corresponding IC design.
B. HDL Simulation Algorithm
The HDL simulation algorithm used in the RaceCheck dynamic analysis engine is based on an event-driven logic simulation algorithm[1]. RaceCheck may also use other logic simulation algorithms, such as cycle-based logic simulation (where timing delays of IC design elements are ignored), but the results will be less accurate. This is because many race logic manifest via simultaneous occurrence of certain events at specific simulation time points. Thus, without consideration of timing characteristics of circuit events, the detection of race logic will be less accurate.
Refer to FIG. 3, which depicts an event-driven logic simulation process flow. The simulation starts by setting the initial simulation time to zero, as indicated by box 11 in FIG. 3. It then checks, as indicated by box 12, if the current simulation time exceeds the user-specified maximum run time, or if there are no more circuit events pending to be evaluated. In either of the aforementioned situations, the simulation is completed (box 13), and the simulation results are generated and depicted to users.
However, if neither of the aforementioned situations is true, the simulator proceeds to process pending events at the current simulation time (box 14, 15 and 16). These new events are either input stimuli that are to be applied to the primary input and/or bi-directional signals of the circuit-under-test (CUT), or are scheduled events for the current time, due to some logic gates' evaluation at one or more prior simulation time points.
If an event to be processed is a signal event (box 15), the selected signal's state is first updated, then all the logic gates driven by this signal will be put into a queue, and these logic gates will be processed after all the current signal events have been processed.
Once all signal events are processed in the current time, any scheduled logic gate events, as well as logic gates in the queue, will be evaluated (box 16). This may result in some logic gates being processed at a future time (the logic gates are either sleeping for some user-specified time(s), or are waiting for one or more trigger signals to change states). Furthermore, one or more output signals of those logic gates may also be scheduled to change state in a future time. All these generate new events, which will be processed as the simulation progresses forward in time.
After all signal and logic gate events are processed, the simulator will then check (box 17) if there are any scheduled zero-delay events. If there are pending zero-delay events, the simulator starts a new iteration (at the same simulator time) to process those zero-delay events (box 17 transitions to box 15); otherwise, the simulator will advance the simulation time (box 18) to the next simulation time point. Then, it repeats the aforementioned simulation process (box 12-18) all over again.
C. Static Race Logic Analysis
Static race logic analysis program traverses the directed graph (e.g., FIG. 2) of a CUT, and detects race logic in the CUT based solely on the structural and time description of the directed graph. No test bench (test pattern) is required. Static race logic may be used in any stage of an IC design cycle, from IC design module development (pre test bench generation phrase) to final regression testing phase (where test benches for the CUT are available). Static Race logic analysis detects the following race logic in a CUT:                Concurrent assignment race events on circuit signals        Concurrent assignment and reference race events on circuit signals        Concurrent invocation race for the Verilog/SystemVerilog $random system function        Concurrent invocation race for any user-defined tasks and functions        Zero-delay combinational feedback loops        
Static race logic analysis generally gives more comprehensive race logic detection results than dynamic race logic analysis, and it runs much faster than dynamic race logic analysis. However, some of the race logic detected by the static race logic analysis may not manifest in the actual CUT field operations because the stimuli to the CUT's chip may not activate all logic in the chip.
D. Dynamic Race Logic Analysis
Dynamic race logic analysis program uses an event-driven logic simulation kernel to simulate the CUT field operations, based on a given user-supplied test bench. It can be applied to a CUT after the IC design is completed, and one or more test benches for the CUT are available. The dynamic race logic analysis program monitors all circuit events throughout the simulation run, and detects the following concurrent race logic in the CUT:                Concurrent assignment race events on circuit signals        Concurrent assignment and reference race events on circuit signals        Concurrent invocation race for the Verilog/SystemVerilog $random system function        Concurrent invocation race for user-defined tasks and functions        
Since dynamic race logic analysis simulates the “real-life” operations of the CUT, it generally gives more precise race logic detection results than static race logic analysis does. Thus, all race logic reported by the dynamic race logic analysis program will likely manifest in the CUT's chip field operations. However, since event-driven simulation process is time-consuming, the dynamic race logic analysis program tends to run much slower than that of the static race logic analysis program. Furthermore, the race logic analysis results are highly dependent on the quality of the user-supplied test benches.